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Capitulo 1 

Introducción 

En el mercado existen muchísimas soluciones de 
VolP. Algunas más populares que otras, y con sus 
variantes en plataformas. En combinación con el 
hardware y marcas disponibles, las variables son 
innumerables. Es por eso que hablaremos de 
supervivencia como concepto y no veremos 
ejemplos específicos. 

La verdad es que no existe la "Su per Plataforma" 
que cumpla con todos y cada uno de los conceptos 
que veremos. Se trata de mi visión personal, basada 
en experiencia adquirida en años 

Todo dependerá del hardware disponible, y por 
supuesto del presupuesto del proyecto. 




Asterisk 1 es sinónimo de VolP. Bajo licencia GPL 
{General Public License"), existen varias alternativas 
basadas en la misma: Elastix 111 , FreePBX lv y otras... 

Sin dudas, una plataforma libre tiene sus 
ventajas, pero sin entrar en polémica, las que no 
son libres (aunque se basen en Asterisk), soluciones 
que incluyen hardware más software, y las 
plataformas propietarias. Todas tienen sus pros y 
contras. 

Sin importar qué solución VolP utilicemos, TODAS 
dependen de 3 factores fundamentales para un 
normal y correcto funcionamiento: 



• HARDWARE 

• SEGURIDAD 

• SUPERVIVENCIA 



El Hardware es obvio. Aunque podemos montar 
Asterisk sobre Raspberry P/, v las limitaciones son 
evidentes. De hecho, las IP PBX de marca, 
comercializan su propio hardware para no 
depender de terceros. 

Seguridad es un mundo aparte que dejaremos 
para otra oportunidad, ya que hay mucho para 
explayarnos. 

Y Supervivencia es el tema de hoy. 
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Que es supervivencia? 

Desde que se empezaron a automatizar las PBX, 
existió la supervivencia. Siempre fue necesario un 
Plan B cuando la tecnología falla y las 
comunicaciones son primordiales 

Cualquiera sea la marca o modelo de central 
telefónica, siempre contaremos con un sistema de 
conmutación automática ante falla de energía 
llamado PSTN Fallback 

Un simple relé que conmuta ante una falla, 
permite al usuario estar siempre comunicado con el 
paso de una línea directa sobre el teléfono en caso 
de contingencia 




La transferencia por fallo de alimentación, es un 
requerimiento en la mayoría de los países a la hora 
de homologar un equipo. Empezando por la FCC 
{Federal Communications Comisión), y la mayoría de 
los fabricantes lo implementan (pero no todos) 

El concepto es simple. 

Ante una crisis, se debe poder garantizar un 
llamado a emergencias 

Como sabemos, VolP significa Voz sobre Protocolo 
de Internet (Voice over Internet Protoco I). Y en este 
contexto, se plantea un problema para las llamadas 
a emergencia ya que puede no quedar definido el 
lugar donde se genera la llamada (desde Internet), 
para poder derivarla al centro de atención 
adecuado más cercano. Y aunque técnicamente es 
factible que las llamadas de emergencia contengan 
la información relativa a la ubicación, aun no existe 
una regulación al respecto, y la seguridad del 
usuario quedaría en manos de quien realice la 
instalación 

Es por esto que hacemos énfasis en la 
supervivencia, y vemos la importancia de una 
correcta implementación 



La voz sobre IP tiene un sin número de ventajas: 
Comunicaciones Unificadas, ACD, IVR, Integración 
con email, Conferencia, Correo de voz, Grabación 
de llamadas, Atención Automática, Texto hablado, y 
un largo etc. Pero... 

La tecnología VolP es frágil 

Abierta, cerrada o propietaria, todas las 
plataformas dependen de factores externos . La 
comunicación de cientos de usuarios puede 
comprometerse por un simple patch cord, o un 
transformador de un valor irrisorio 

Todas las marcas y/o plataformas se auto- 
venderán como las mejores de mercado. Y en cierta 
medida lo son, pero cuando el sistema se cae, 
siempre será culpa de un tercero 

Es responsabilidad del implementador, eliminar 
los factores de riesgo 
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Primeros pasos 



Imaginemos una red compleja, de 500 internos 
con una casa central, una fábrica, y 2 sucursales 
más: 




50 



Una opción es instalar una PBX en casa central, y 
en las sucursales los internos necesarios. 

Seguramente, este será el primero de los 
proyectos a presentar, y el presupuesto más 
económico que le ofrecerán al usuario final 



El instalador experimentado tomará la ventaja, al 
demostrar la ineficiencia del proyecto y la completa 
falta de supervivencia, con los riegos que conlleva 

A primera vista. Cuál es el principal problema? 

Antes de continuar leyendo, analiza la imagen. 




Tomate tu tiempo... 



Si se corta un vínculo? 



Frente a la perdida de conectividad de cualquier 
sucursal, la misma quedaría incomunicada. Y peor 
aún, ante la caída de casa central TODA la red 
quedaría incomunicada. Es decir: La integridad de 
las comunicaciones de la empresa dependen de un 
solo cable (figurativa y tácitamente hablando) 

El objetivo es presentar un diseño topológico que 
no contenga un punto único de falla. 

Un "Vínculo" depende de infinidad de factores 
externos, pero a los efectos prácticos del ejemplo, 
vamos a empezar por centrarnos en el proveedor 
de internet 
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2WAN 



Contar con 2 ISP {Internet Service Provider) es solo 
el primer paso 

No es solo cuestión de instalar un segundo 
proveedor y ya. Hay varios factores a tener en 
cuenta, simplemente usando el sentido común 

2 líneas ADSL siguen teniendo el mismo riesgo. 
Es muy probable que si una línea se cae, una 
segunda línea tenga los mismos inconvenientes 



Un ejemplo sería contratar un ISP corporativo + 
backup de TV Cable, pero claro que dependerá de la 
disponibilidad técnica de la zona (Última milla) 




2 Proveedores distintos 
2 Tecnologías distintas 



La cuestión es disponer de 2 proveedores 
distintos, con 2 tecnologías distintas 



Capitulo 5 

Router 2 WAN 

Para trabajar con 2 WAN, necesitaremos de un 
router 2 WAN (Valga la redundancia) aunque 
existen en el mercado router que trabajan en 
cascada sumando 2 WAN. Lo primordial aquí, es 
evitar el balanceo de cargas. 

Como su nombre lo indica, un balanceador de 
carga, balancea la carga, conmutado entre las WAN, 
y por consiguiente, cambiando de IP regularmente 

Aunque trabajemos con dominio (y no con IP 
fija). La conmutación constante podría sobre exigir 
a los servidores DNS en forma innecesaria, y la 
comunicación se vería interrumpida con micro 
cortes. 

La VPN (altamente aconsejable en nuestro 
ejemplo) suele trabajar con IP fija y también se vería 
perjudicada, por lo que debemos descartar el 
balanceo de cargas. 

El router con 2 WAN debe trabajar como backup. 
Comúnmente llamada Alway On. 

Esta función, sólo conmuta entre las WAN ante 
una falla. Es decir que trabajaremos siempre con un 



ISP, y ante una eventualidad, conmutar 
automáticamente con la otra WAN 



-í 2 



WAN 



• * • # 

■■■■ 




NO Balance Carga 



Es aconsejable en estos casos (si el router lo 
admite) configurar una alerta por email al 
responsable de sistemas, por la falla de la conexión 
principal. Si no, estaríamos "ciegos" y no nos 
enteremos de la irregularidad 

Es muy difícil que ambas conexiones fallen (sobre 
todo si se trata de 2 tecnologías distintas), pero 
debemos estar notificados, y realizar el reclamo 
pertinente. 



Capitulo 6 

IP PBX Local 



Ya disponemos de 2 WAN, pero una red 
centralizada es peligrosa. Son muchos los factores 
que influyen para que todas las comunicaciones se 
pierdan. 

Debemos pensar en una PBX trabajando en forma 
local, enlazadas de forma tal, que interactúen como 
una única central, de forma tal que para el usuario 
final le resulte transparente. 



El Gateway también contribuye a la 
descentralización si así se lo requiere. 

Las marcas de hardware, impulsan a este tipo de 
supervivencia, porque comercializan más hardware, 
y aunque es una excelente solución, el presupuesto 
se ve incrementado drásticamente (Y recién 
empezamos con el análisis) 




Ya estamos acostumbrados a una solución local 
(Una PBX en el mismo establecimiento). Y es esta la 
imagen que tiene el usuario final en la cabeza. 
Como administradores debemos recrear ese 
concepto, y esto se logra gracias al plan de 
numeración. 
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Plan de numeración 



Debemos planificar la numeración integral de la 
red. Lo cual significa, pensar en que marcaremos 
para comunicarnos con los internos y acceder a 
línea externa, y a las innumerables prestaciones de 
la PBX como desvío, no molestar, aparcar, captura, 

etc. Por cada una de estas funciones, marcaremos 
un código que ya viene preestablecido, pero al 
cambiar las centenas, deberemos re-enumerarlas. 

Si por defecto se captura una llamada con 40, la 
centena 4 ahora está ocupada con una sucursal, y 
debemos cambiar el código 40 por uno nuevo y la 
captura se hará con los dígitos que le asignamos. 

Primero, planearemos cada una de las centrales 
con una o dos centenas, según sea el caso. 



Casa 
Central 


Fábrica 


Sucursal 1 


Sucursal 2 


1 00-299 


300-399 


400-599 


600-699 



Aquí utilizamos 6 centenas, lo que limita mucho el 
uso de funciones. 



0 


Operadora 


1 


Fabrica 


2 


Casa central 


3 


Casa central 


4 


Sucursal 1 


5 


Sucursal 1 


6 


Sucursal 2 


7 


Disponible 


8 


Disponible 


9 


Toma de línea 



El 0 es universalmente llamado a operadora. 
Aunque no tenemos ninguna limitación técnica para 
renombrarla, no es aconsejable. 

El 9 estaría reservado para toma línea. 

Entonces solo contamos con 7 y 8 para funciones. 

También podríamos contar con el asterisco (*) y el 
numeral (#), pero no todas las marcas o 
plataformas admiten estos dígitos en el plan de 
numeración. Si se puede, bienvenido sea, ya que 
seguramente lo aprovecharemos. 



Si venimos de una migración, y los usuarios ya 
están acostumbrados a capturar por ejemplo 
marcando 40, los más amigable es que capture con 
*40 

Contar con solo una centena para funciones resulta 
complicado, ya nos veremos obligados en la 
necesidad de utilizar 3 o 4 dígitos para poder cubrir 
la totalidad de las funciones disponibles. 

Problemático, porque al usuario final le empieza a 
resultar incómodo utilizar las funciones más 
regulares, por lo extensa de las mismas. 



Función 


Numeración 
por defecto 


Numeración 
luego del cambio 


Captura 


40 


80 


Captura 
dirigida 


4+ N°de 
interno 


852 + N°de 
interno 



Aunque no se vea a simple vista, en el ejemplo 
realizamos 3 sacrificios: 

• Para que 80 sea parecido a 40 y seguir usando 
sólo 2 dígitos para la captura y la similitud de la 
numeración, la decena 0 ya no estará disponible. Si 
contábamos con 8XX y sus 99 números, ahora 
contamos con solo 89. 

Perdimos desde el 800 al 809 (sacrificamos una 
decena) 

• La centena 8XX consta de 3 dígitos. Al utilizar una 
función con sólo 2 dígitos, la central espera el 3 
dígito que nunca llega. Luego de la pausa inter- 
dígitos y determinar que solo se utilizaron 2 dígitos 
y que los mismos están reflejados en el plan, actúa 
en consecuencia con la captura, demorando la 
función. 

Esto que suena confuso, significa que luego de 
marcar 80, hará una pausa, y luego capturará la 
llamada. La función no es inmediata 

• La elección del 852 no es por azar. También 
debemos pensar en la "usabilidad" para lograr que 
la experiencia del usuario sea más amigable. 

852 es fácil de recordar, porque es fácil de marcar 
debido la distribución del teclado. 




Lamentablemente son pocos los números con esta 
propiedad, y más aún en un plan de numeración 

Por supuesto de 3 dígitos es mejor que 4 dígitos, 
cuando queremos reenumerar a todas las 
funciones. Si contáramos con solo una centena, con 
80 números no podríamos cubrir la totalidad de las 
funciones, y definitivamente perderíamos 
usabilidad. 

En nuestro ejemplo, contamos con 2 centenas: 7xx 
y 8xx, pero no siempre tenemos suerte cuando 
estamos en el campo 

Si el cliente es un hotel con 10 pisos, y usamos una 
centena por casa piso; utilizaremos 4 dígitos. 

Una buena práctica y que todo buen instalador está 
obligado a configurar, es el uso de Quick Dial para 
estos fines. 
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Redundancia 

La primera regla de la supervivencia, sería la 
redundancia. Todo duplicado: Hardware, Servicios, 
etc. La contra es evidente: Se duplican los costos 

Debemos entonces aprovechar los recursos 
disponibles 




El concepto es simple. Un ruteo alternativo, por 
no disponibilidad de la IP PBX 



No será válido si contamos con una única PBX 
trabajando en forma local, pero en nuestro 
ejemplo, contamos con 3 PBXs dentro de la misma 
red. Entonces un teléfono podría registrarse en la 
PBX local, y en una remota 




Es una excelente manera de aprovechar los 
recursos, pero debemos tener cuidado en algunos 
aspectos: 



• Estamos duplicando licencias ya que el teléfono 
se registra en 2 PBXs, y dependiendo de la 
plataforma a utilizar, las mismas son gratuitas o con 
costo 

• El hardware (PBX) debe estar preparado para 
recibir de la noche a la mañana el doble de tráfico, 
ante un evento de crisis 

• Aunque la mayoría de los teléfonos del 
mercado admiten varias cuentas SIP, no todos 
conmutan automáticamente. Los usuarios deben 
estar capacitados para acceder a la segunda cuenta 
manualmente. 
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Comunicaciones Unificadas 

Si se rompe el teléfono, el usuario puede acceder 
a su interno por SoftPhone o vía Web Service. 




El uso de web service es sin dudas, la manera 
más rápida y fácil de reemplazar un aparato de 
teléfono descompuesto. El usuario solo requiere 
loguearse con su propio número de teléfono y 
contraseña, recuperando así su interno 



No todas las plataformas cuentan con Web 
Service, y la mayoría son licenciadas. 

Es uso de softphone dependerá si ya está 
instalado y configurado previamente. 

Son muchos los usuarios que prefieren un 
teléfono físico antes que el softphone, y son reacios 
a utilizarlo. 

Hay plataformas que cuentan con auto 
aprovisionamiento para softphone, facilitando una 
solución temporal vía remota. 
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PBX Híbrida 

Volviendo a la PBX local, la mayoría de las 
comunicaciones serán locales y sólo las 
comunicaciones remotas será IP. Entonces, porque 
debemos montar una red completamente IP? 

Los fabricantes de centrales telefónica, que 
siempre trabajaron en forma analógica, 
desarrollaron soluciones híbridas, con lo mejor de 
los dos mundos. 



Todos sus internos son analógicos, y el vinculo 
entre centrales es por VolP 

''Analógico es robusto " 

En la mayoría de los casos contaremos con líneas 
analógicas (Aunque sean de backup). Y si se pierde 
algún vínculo IP, no estaríamos incomunicados. 
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Bypass FXS/FXO 

Como vimos antes, desde sus inicios, los 
fabricantes de centrales telefónicas, han incluido 
algún sistema de supervivencia. Un simple relé que 
conmuta ante una falla de energía 




Los Gateway que combinan puertos FXS y FXO 
también cuentan con este sistema de supervivencia 




Cada FXS queda unida eléctricamente con una 
FXO. 

Es importante entonces, la correcta elección del 
hardware mixto, ya que uno o dos Gateway 
convencionales, que trabajan en forma separada 
(un Gateway con puertos FXS y otro con puertos 
FXO), no contarían con este tipo de supervivencia 

Estos Gateway no solo cuentan con una solución 
ante un problema eléctrico, son "más inteligentes", 
ya que además cuentan con supervivencia por corte 
del vínculo con la PBX. 




Dial Plan 
Survivability 



Los Gateway también cuentan con Dial plan, 
manteniendo restricciones y las limitaciones que 
correspondan según las tablas de ruteo internas. 

Hasta es posible el ruteo alternativo en base a 

QoS {Quality of Service, o Calidad de Servicio) y no 
necesariamente por pedida total de la conexión 

Entonces, deberíamos de crear un enrutamiento 
de llamadas combinado entre tablas locales y Proxy 
externo. 

Si los paquetes keep-alives enviados 
periódicamente contra la PBX dejan de ser 
respondidos el Gateway puede conmutar a modo 
Emergencia y a partir de ese momento actúa como 
proxy de contingencia para los teléfonos SIP que 
hayan sido registrados 
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Líneas IP 



Se dice que una central IP debe trabajara con 
líneas IP, para evitar la conversión entre distintas 
tecnologías (Digital / Analógica) 

Contamos con el VolP Provider en la nube, lo que 
nos da la libertad de registrar la misma línea en 
todas nuestras PBX. 

Registradas, pero no habilitadas 

Y así, ante una crisis, con una simple tilde 
podremos habilitar las líneas en la red 

Por ser líneas IP, no dependemos de hardware. 
Solo dependemos de licencia. 



Capitulo 13 

ARS | Selección automática de ruta 



Configuramos el ARS para economizar llamadas 
por la ruta más conveniente. Y también deberíamos 
configurarla pensando en la supervivencia 

Ejemplo: Las llamadas locales deben salir por el 
troncal digital E1 para aprovechar un paquete de 
llamadas gratis 

Debemos configurar un segundo Routing Plan 
Priority para que las llamadas salgan por líneas de 
backup (analógicas, IP, o incluso en otras PBXs) 

Dependiendo del tráfico y la relación con la 
cantidad de internos, un troncal digital rara vez se 
satura ya que equivale a 30 canales. Sólo cuando el 
IP trunk esté totalmente ocupado o caído {reorder), 
las llamadas seguirán por la ruta alterna (backup). 
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Telulares 



Una red celular es una poderosa herramienta: 

D Dentro de una misma flota, las comunicaciones 
son gratuitas 

D La calidad del audio es excelente (A veces 
mejor que la de VolP) 

D Rara vez falla 

Si la plataforma lo permite, al momento de 
configurar el plan de numeración para 
interconectar la red, usemos como segunda 
prioridad la red de telulares 
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Resguardo eléctrico 

Centrales telefónicas analógicas, y Gateway 
incluyen supervivencia por corte de energía, pero si 
contamos con cientos de teléfonos IP. 
Forzosamente debemos contar con algún tipo de 
energía alternativa (UPS, generador eléctrico), y lo 
cierto es que rara vez contaremos con un equipo 
que de carga a cientos de puestos de trabajo. 

Contemos con al menos un switch POE {Power 
Over Ethernet), para administrar los teléfonos que 
siempre estarán alimentados, y ubiquemos a estos, 
estratégicamente dentro de la red, para que al 
menos un teléfono de cada sector funcione ante 
una falla eléctrica. 




También podemos utilizar la numeración de los 
internos para saber cuáles funcionarán cuando falle 
la energía. Por ejemplo, todos los internos 
terminados con 0 (XXO) estarán conectados al 
switch POE. Entonces, durante una crisis, si es 
necesario comunicarse con el interno 414, 
sabremos que podremos comunicarnos con el 
interno 410 que se encuentra en el mismo sector. 
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Conclusión 



• Usar el sentido común. 

• Usar "buenas prácticas". 

• Utilizar hardware de primera marca. 

• Investigar sobre los recursos y consejos 
que nos brinda la plataforma que 
utilicemos. 

• Si el presupuesto lo permite, redundancia 
en todo. 

Y recordar la Ley de Murphy: 

"Si algo puede salir mal, saldrá mal" 



Links de interés 



1 http://www.asterisk.org/ 

" https://www.gnu.org/copyleft/gpl.html 

111 http://www.elastix.org/index.php/es/ 

lv http://www.freepbx.org/ 

v http://www.raspberrypi.org/ 

Asterisk 

https://wiki. asterisk.org/wiki/dosearchsite. action?where=AST& 
spaceSearch=true&queryString=survivability 

Sangoma 

http://www.sangoma.com/solutions/branch-office- 
survivability/ 

Audiocodes 

http://www.audiocodes.com/glossary/sas 
Cisco 

http://www.cisco.com/c/en/us/products/collateral/unified- 
communications/unified-survivable-remote-site- 
telephony/data sheet c78-570481.html 

Panasonic 

http://panasonic.net/pcc/products/pbx/products/pbx/kx ns1 0 
OO/features/flexibility.html 



